Today there are guidelines or other rules or that apply to almost all graphical user interfaces (GUI) to be designed for systems, platforms or computing environments. The guidelines may stem from a desire to make the GUI user-friendly, from a technical restriction in the implemented system, or from legislation that requires the GUI to be accessible to the visually impaired, to name a few examples. Such guidelines are sometimes very extensive which means that it may be difficult for the individual designer to learn them in their entirety so that they can be applied in the design process. Also, the guidelines may change from time to time so there is a need for timely updates. UI guidelines have been provided to the designer in hard copy or in a form that is otherwise not integrated with the design/development environment, for example by storing them in a file of the computer system.
An exemplary design/development procedure may include the following separate phases: 1) A solution manager, an infrastructure architect and a UI designer capture user requirements for the UI, determine one or more user scenarios and thereafter create a UI design. 2) The solution manager, the infrastructure architect and the UI designer decide on an UI architecture and thereafter design, test and validate the UI design and deliver a UI prototype together with a specification. 3) The infrastructure architect, an application developer and the UI designer build the technical design, implement the technical and UI design while attempting to follow the UI guidelines and rules. 4) A quality manager, the application developer and the UI designer verify functional behavior of the application, review the UI according to the UI requirements and retest/modify the application until finished.
It happens that developers and designers violate UI rules and standards. Sometimes this is inadvertent, such as when the designer or developer is not aware of the specific rule that applies. For example, a UI designer may create a UI prototype taking into account any or all UI guidelines and thereafter forward the prototype to a developer to create the actual application. The developer, in turn does not know what UI requirement(s) shaped the UI designer's work and may violate it/them in creating the application. Thus, UI requirements may be “lost” in the handover from designer to developer.
In other situations, the designer or developer ignores a certain guideline believing that it does not apply, or because compliance would require substantial effort. This scenario sometimes occurs in organizations where a large number of UI requirements are posted without sufficient efforts in integrating them with each other or making sure they are consistent. As a result, some applications are created with UIs that contain errors, inconsistencies or other defects. Accordingly, problems may result when UI prototypes have no impact on the development tools to be used, or when application developers have insufficient access to user requirements and guidelines.